O'Reilly's book "Practical UNIX Security" has a good discussion of IFS's. That might answer some of your questions. It's a good book to dig through anyway. ________________________________________________ > What is IFS, anyway? I've seen it, but never anything to tell what > it is, what it does, what IFS stands for. I don't know why I think this (ie, where I found the information), but I think IFS stands for Internal Field Separator. It controls the breaking of the command line into "words"; for our purposes, the most important thing about this is that the name of the command to be executed is delimited by characters in IFS. This is the basis for attacks such as the one described, in which IFS is set to include an unusual character such as a slash. If IFS contains slash and the usual whitespace characters, then "/bin/rm foo.c" will be interpreted to mean "run the command "bin" with arguments "rm" and "foo.c"", because the / is treated more or less as whitespace. As for how to defend against such an attack, as someone else already mentioned, most (all?) shells that support IFS do not use it when interpreting variable assignments, thus making it possible to reset IFS as the first thing in the script. Why does IFS exist at all? Well, I'm not S. R. Bourne; I don't know. But I conjecture it's because it makes certain shell-script tasks easier. For example, if one has a passwd line, one can crack it into its fields very easily with something like IFS=: set $record This has its hazards, certainly; for example, at least one sh I have access to misbehaves if $record begins with a dash. But it does have its uses. (Not that I fully support it; in fact I think it would be better to get rid of IFS and achieve those ends other ways. I'm trying to explain, not justify.) der Mouse mouse@collatz.mcrcim.mcgill.edu